One of the most important societal changes of recent times has been the emergence of the Internet, more particularly, the World Wide Web (e.g., the Web), as a predominant communications medium. The Web represents all the computer's on the Internet that offer users access to information and documentation media interactive hypermedia, or Web pages. Web pages describe documents in which hypertext links are used connecting a multitude of combinations of graphics, audio, video, and text. Such combinations are often interlined and interconnected in nonlinear, nonsequential manners.
The vast majority of corporations in the modern business world have adopted Web based technology to accomplish their normal business functions. These businesses have moved much of their basic processes, activities, functions, and the like “on-line” wherein the processes/activities are available electronically to an interwoven network of business suppliers, and operators, as well as customers. Transaction processing is one such function.
Transaction processing is the prototype of information processing system in business service organizations. Transactions referred to sets of discrete inputs, for example, submitted by users at unpredictable intervals, which call for database searching, analysis, and/or modification. The server evaluates the requests and executes them in response to user queries. Response time (the elapsed time between the end of a request and the beginning of the reply) is an important characteristic of the performance of a transaction processing system, wherein “real-time” teleprocessing is the desired goal. Some transaction-processing systems often incorporate private telecommunications networks. However, a majority of the more modern transaction processing systems are moving towards Internet based standards. Internet based transaction processing systems are increasingly comprising the foundation of service industries such as banking, insurance, securities, transportation, and libraries. However it should be noted that Web, or Internet, or Intranet settings are merely typical.
The general problem with such transaction processing systems is how to represent and apply business rules in a transaction-processing RDBMS environment. The specific case of the problem (which necessarily employs a technology applicable to the general problem) is how to represent and apply business rules that define a transaction's approval process (typically, a list of managers who must approve the transaction) in a transaction-processing environment. For example, expense reports and purchase requisitions typically require approvals by one or more employees in a managerial hierarchy, and transaction-processing applications such as Oracle's Web Expenses and Internet Procurement must somehow define and apply the rules that determine how far up the hierarchy a transaction's approver list must ascend. Transactions often require approvals by functional specialists (e.g. HR representatives, financial analysts, and legal departments) before or after all approvals in the hierarchy have occurred, and a transaction-processing application must make special provision for such non-hierarchical approvers.
Until now, each transaction-processing application in an RDBMS business environment has hard-coded either a fixed set of business rules, or a fixed framework for defining business rules on a fixed set of “transaction attributes” (decision variables) such as a transaction's total (e.g. dollar) amount. In either case, the application limits its rules to a fixed list of available hierarchies (typically a single managerial hierarchy). Such application's provisions for non-hierarchical approvers are similarly fixed and non-extensible. If an organization using such an application desires to extend the application's approval rules beyond the fixed limits imposed by the application's approval-rules paradigm, for example by:    (i) defining new transaction attributes and including them in the business rules;    (ii) defining a new approvals hierarchy and requiring it in the rules;    (iii) defining approval groups for non-hierarchical approvers; or    (iv) altering the approver list in various possible ways at runtime; the organization must customize the application's source code to achieve the desired extension. Moreover, it has so far been wholly impractical for several transaction-processing applications to share a set of approval rules or a single paradigm or environment for defining such rules. Even if, in human terms, the business rules are the same across several applications, each application has its own architecture for representing and calculating on the rules, so the rules must be translated, by hand, by skilled personnel, into each application's paradigm.